System and method to synchronize two or more object management systems

ABSTRACT

A distributed reader and writer&#39;s lock to synchronize object management systems is disclosed. The purpose of the lock is to control access to information that is shared by corresponding object management system components on multiple object management systems. An object management system is a computer-based system for storing, naming, and manipulating objects. One lock is created for each object management system component associated with a particular service within the system. The locks communicate over an interface definition language interface. The reader/writer&#39;s lock is created by a remote component synchronization module, which acts as an agent for the object management system component. The lock exposes functions to request or release a write lock and to request or release a read lock.

BACKGROUND

[0001] 1. Field of the Invention

[0002] Embodiments described herein are directed to a distributed readerand writer's lock to control access to information shared bycorresponding object management system components on multiple objectmanagement systems. An object management system is a computer-basedsystem for storing, naming, and manipulating objects. One lock iscreated for each object management system component that is associatedwith a particular service in the system. The locks communicate with aninterface definition language or similar language.

[0003] 2. Related Art

[0004] At present, multiple processes are synchronized on a singlenetwork processor running the Intel® Internet Exchange Architecture(“IXA”) object management system. Intel® IXA is a packet processingarchitecture that provides a foundation for software portability acrossmultiple generations of network processors. Intel® IXA focuses on Intel®network processors and is based on microengine technology, the Intel®XScale™ microarchitecture and the Intel® IXA Hardware Abstraction Layer.

[0005] Through Intel® IXA, a greater choice of standards-based, highperformance communications building blocks is made available. Thesebuilding blocks provide faster time-to-market, greater designflexibility and extended time-in-market for next-generation networkingsolutions. Intel® IXA empowers more rapid deployment of differentiated,reliable and intelligent services for the converged Internet Protocolnetwork, while maximizing return on capital investment.

[0006] There exists, however, a legitimate business need for an approachwhich provides an object management messaging system that allows tasksand high-level programming frameworks such as the Active ComputingElement (“ACE”) to send messages to one another on multiple networkprocessors in the same manner as they would on a single networkprocessor. Such an approach is beneficial for users who intend to writeIXA applications to run on multiple network processors.

[0007] In addition, with such an advancement in the field, users whodevelop applications for a single network processor will be able toupgrade to using several processors without having to rewrite any of theobject management system messaging code. This approach is not limited toIntel architectures; it may also be implemented on other non-Intelrelated architectures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A detailed description of embodiments of the invention will bemade with reference to the accompanying drawings, wherein like numeralsdesignate corresponding parts in the several figures.

[0009]FIG. 1 is a diagram of the synchronization blocks on a singleobject management system, according to an embodiment of the presentinvention.

[0010]FIG. 2 is a block diagram of the reader and writer's lock functioninterface, according to an embodiment of the present invention.

[0011]FIG. 3A and FIG. 3B together form a flowchart showing the stepsinvolved in a local write lock request, according to an embodiment ofthe present invention.

[0012]FIG. 4 is a flowchart showing the steps involved in a local readlock request, according to an embodiment of the present invention.

[0013]FIG. 5 is a flowchart depicting the steps involved in a remotewrite lock request, according to an embodiment of the present invention.

[0014]FIG. 6 is a flowchart showing the steps involved in a local writelock release, according to an embodiment of the present invention.

[0015]FIG. 7 is a flowchart showing the steps involved in a remote writelock release, according to an embodiment of the present invention.

DETAILED DESCRIPTION

[0016] The following paragraphs describe a distributed reader andwriter's lock 100 for synchronizing object management systems. An objectmanagement system is a computer-based system for storing, naming, andmanipulating objects. The distributed reader and writer's lock 100 isone component in the synchronization system of a multiple objectmanagement system. The purpose of the distributed reader and writer'slock 100 is to control access to information shared by correspondingobject management system components 140 on multiple object managementsystems. One distributed reader and writer's lock 100 is created foreach object management system component 140 associated with a particularservice within the system.

[0017] According to one embodiment of the present invention, asillustrated in FIG. 1 and FIG. 2, the distributed reader and writer'slock 100 communicates over an interface definition language interface110 or similar language interface. A remote component synchronizationmodule 120 creates the distributed reader and writer's lock 100. Theremote component synchronization module 120 acts as an agent for theobject management system component 140. The distributed reader andwriter's lock 100 exposes functions to request a read lock 200 and 20release a read lock 200 and to request a write lock 210 and release awrite lock 210.

[0018] As seen from a system perspective, one remote componentsynchronization module 120 may have one write lock 210 at a time,although it may have several read locks 200. The write lock 210 is onlygranted to the remote component synchronization module 120 when alloutstanding read locks 200 are released, and all outstanding read lock200 requests are granted and released. The remote componentsynchronization module 120 that has the write lock 210 may acquire oneor more read locks 200, but read lock 200 requests are blocked for otherremote component synchronization modules 120 until the write lock 210 isreleased. In the absence of a write lock 210, any remote componentsynchronization module 120 may acquire one or more read locks 200.

[0019] The distributed reader and writer's lock 100 communicates withcorresponding locks on other object management systems through ix ringobjects, which function as ring buffers. The code that marshals themessage data and that sends and receives data from the rings isinterface definition language 110 generated. The code encapsulates theix ring and interface information into an ix base t object 220.

[0020] In the Internet Exchange Architecture (“IXA”) system, thefunctions that support incoming messages are known as skeletonfunctions, while those that support outgoing messages are referred to asstub functions. A single interface definition language interface 110uses only one ix_base_t object 220 to support the skeleton interface andone ix_base_t object 220 for each connected object management system tosupport the stub interface.

[0021] The distributed reader and writer's lock 100 manages theix_base_t object 220 that handles the skeleton interface. Thedistributed reader and writer's lock 100 offloads management of the stubinterface to a list controller 130 and provides two callback functionswhile registering as a client of the list controller 130. The creationand partial initialization of an ix_base_t object 220 as a stubinterface to a new object management system being connected to thesystem is one such function. The initialization is performed by theinterface definition language 110 generated stub initializationfunction. The other function is the clean up and destruction of anix_base_t object 220 when an object management system is disconnectedfrom the system. The clean up is performed by the interface definitionlanguage 110 generated stub clean-up function. The distributed readerand writer's lock 100 does not track the active ix_base_t objects 220because the list controller 130 provides a function to iterate throughall of the lock's current ix_base_t stub objects. The list controller130 further maintains a communications list 150 and is connected to thecommunications controller 160. The Application Program Interfaces(“API”) presented to the remote component synchronization module 120 aresynchronous. APIs are sets of routines, protocols, and tools forbuilding software applications. An API thus serves as a programmaticinterface for interprogram communications or for interfacing betweenprotocol layers.

[0022] When the remote component synchronization module 120 makes a read200 or write lock 210 request, the function does not return until thelock is acquired. Since all incoming messages are received in the sameix_base_t object 220, including replies to requests sent by the localobject management system, the skeleton code must not block for anindeterminate period. Because of this, the distributed reader andwriter's lock 100 runs the skeleton code in a separate thread. Using athread protection mutex in the skeleton code is acceptable, whereby themutex is a program object that allows multiple program threads to sharethe same resource, but not simultaneously.

[0023] A remote object management system may request a write lock 210when the local object management system has a read lock 200. An objectmanagement system does not know of the status of read locks 200 on otherobject management systems. Since the time that a read lock 200 may beheld is undetermined, it follows that the skeleton code cannot besynchronous. That is, if a write lock 210 request is received fromanother object management system, the skeleton code may not wait untilthe read lock 200 is released. Thus, the local object management systemmust respond with a callback to the requesting object management systemwhen the lock becomes available.

[0024] Each distributed reader and writer's lock 100 module contains areader and writer's lock component, wherein the write lock 210 may beadjusted through the interface definition language interface 110. Thatis, only a remote module may set the lock, and a separate variablemaintains the state of the local write lock 210. The reason for this isthat the module must grant local read locks 200 if the write lock 210 islocal, yet read lock 200 requests are blocked if a remote module has thewrite lock 210.

[0025] Algorithms are employed to describe the main flow only. Forinstance, timeout handling is not shown. Wherever a timeout can occur, astep is repeated up to the number of retries set during initialization.Should a timeout still occur, the function returns with a timeoutindicator set. If the function detects an error, it returns the error tothe remote component synchronization module 120 that is using thestandard ix_error encapsulation facilities provided by an actionservices library.

[0026]FIG. 2 illustrates the distributed reader and writer's lock 100function interface. It depicts the read lock 200 request, read lock 200release, write lock 210 request, and write lock 210 release asoriginating at the remote component synchronization module 120 andextending to the distributed reader and writer's lock 100. A lock createand lock destroy similarly originate at the remote componentsynchronization module 120 and extend to the distributed reader andwriter's lock 100 into the interface definition language interface 110.The create ix_base_t 220 function and the destroy ix_base_t 220 functionare shown as stemming from the list controller 130 to the distributedreader and writer's lock 100 into the interface definition languageinterface 110. From the distributed reader and writer's lock 100 to thelist controller 130, extends the register callbacks function and theiterate ix_base_t objects 220 function. In addition, the interfacedefinition language interface 110 receives messages from other locks aswell as sends messages to other locks.

[0027]FIG. 3 shows the steps involved in making a local write lock 210request. If a write request is already pending, as questioned in step300, the system must wait until its pending status drops, as depicted instep 305, and then increment the pending semaphore and continue, asshown in step 310. That is, the semaphore operates as a variable with avalue that indicates the status of common resource. It locks theresource that is being used. The process needing the resource checks thesemaphore to determine the resource's status and then decides how toproceed. As described in step 315, if the local module already has thewrite lock 210, then the system increments a local write lock 210 count.If the write lock 210 is set by another object management system, thesystem must wait, as illustrated in step 320, for it to be released. Ifan object management system has just released its local lock and is inthe process of sending the release to remote object management systems,as shown in step 325, the system must wait until the release option iscomplete. A clear-pending lock is employed here. Next, as depicted instep 330, the lock contention mutex is locked and a random number iscreated for resolving write lock 210 contention. As shown in step 335,the system then checks a variable dedicated to write lock 210arbitration counting. If the value is greater than zero, a request hasbeen received by a remote object management between steps 320 and 325.As such, the lock contention mutex is released and the flow returns tostep 320. Otherwise, the arbitration count is incremented, asillustrated in step 350. As described in step 355, the lock's 210arbitration identification is set to the local object management systemidentification. Its priority is also set through the generation of abound random number. The lock contention mutex is then released, asshown in step 360. For each connection returned through an iteratorprovided by the list controller 130, a write lock 210 request is made tothe remote reader and writer's lock, as illustrated in step 365. Step370 then examines whether the request failed. If a request fails becauseof contention in a remote module, the local write lock count isdecremented, as shown in step 375, and the process repeats from step320, as shown in step 380. Instead of creating a new random number forresolving write lock 210 contention, the request's priority is bumpedbeyond the upper boundary of the random number range. This guaranteesthat requests re-entering arbitration are afforded higher priority thannew requests. The size of the random number generation range must be lowenough to allow the arbitration to bump several times without integeroverflow; enough to accommodate the maximum size of the pending requestqueue. If the request did not fail, as depicted in step 385, when allremote modules have provided the write lock 210 to the requestingmodule, the process returns without setting the write lock 210 in thelock component. This allows the local module to grant read locks 200.

[0028]FIG. 4 shows the steps involved in making a local read lock 200request. This function does not result in any request being passed overthe interface definition language interface 110. The algorithm is asfollows. As shown in step 410, the request is sent to the local lockcomponent. Step 420 then examines whether a remote module owns the writelock 210. If a remote module does not own the write lock 210, the lockis granted, as shown in step 430. If a remote module owns the write lock210, as depicted in step 440, the write lock 210 is blocked. Step 450shows that the request is then retried. If the available time for therequest expires, as illustrated in step 460, the process repeats untilthe maximum number of retries is reached.

[0029]FIG. 5 shows the steps involved in making a remote write lock 210request. This request is received over the interface definition languageinterface 110. Each lock module is responsible for ensuring that itnever sends a request to remote object management systems if it alreadyowns the write lock 210. Therefore, more than one call to this functionwithout an intervening release of the write lock 210 will only occurduring write lock 210 contention. This allows the ownership of the writelock 210 to be changed during the write contention interval, where thewrite contention interval is, the time it takes for the requestingmodule to be granted the write lock 210 by all other modules.

[0030] As shown in step 510, the lock contention mutex is locked, andthe arbitration count is checked. Step 520 examines whether this valueis greater than zero. If the value is not greater than zero, the countis incremented, as illustrated in step 530. If the value is greater thanzero, a request has been previously received. The contention for thewrite lock 210 must thus be resolved, as shown in step 540. The resolvewrite lock contention function is called when a remote object managementsystem requests a write lock 210, yet the write lock 210 contentionvariables, priority and identification, have either been set by a localrequest or by a previous invocation of the write lock 210 arbitrationfunction.

[0031] The write lock 210 arbitration function assumes that a write lock210 contention mutex has already been locked by the time that it hasbeen called and that it will be unlocked after the function hasreturned. The arbiter examines the values of priority andidentification. If the requested priority is different than the currentpriority, the arbitration winner is decided by priority. Otherwise, thearbiter decides the winner based on object management systemidentification. It is required that each object management system in amultiple object management system has a unique identification. If thearbitration winner is the remote object management system, thecontention variables in the local lock are changed, and the arbitrationfields passed by the remote object management system are returnedunchanged. In contrast, if the object management system alreadyspecified in the local arbitration prevails, the local variables areleft unchanged, and the arbitration fields are fixed to the values inthe local variables.

[0032] Step 550 examines whether the remote object management systemprevailed in arbitration. As shown in step 560, if the remote objectmanagement system loses arbitration, the lock contention mutex isreleased and information about the arbitration winner to the requestingobject management system is returned. Otherwise, as illustrated in step570, the request is sent to the lock component, which will block untilall outstanding read locks 200 are released. The lock contention mutexis then released, as depicted in step 580. The steps outlined abovecannot be executed in one function because remote requests are receivedin the interface definition language skeleton code, which must not blockfor an indeterminate period. Therefore, the incoming request must beasynchronous to the reply.

[0033]FIG. 6 shows the steps involved in a local write lock 210 release.As shown in step 610, a clear pending lock is set to prevent the localobject management system from processing another request until thecurrent lock has been released from all remote object managementsystems. The write lock 210 contention mutex is then locked and thewrite lock 210 count is decremented, as illustrated in step 620. Step630 then examines whether the write lock 210 count is zero. If the writelock 210 count is zero, as shown in step 640, the write lock 210contention variables, identification and priority, must be cleared.Otherwise, some other module on the local object management system has awrite lock 210. In that case, the lock contention mutex must bereleased, as depicted in step 650. Step 660 describes the calling of thewrite lock 210 release functions on remote modules over the interfacedefinition language interface 110.

[0034] This is achieved in two stages-one to clear the arbitrationvariables in the remote object management systems and one to enablearbitration for the next request. Otherwise, in a system of three ormore object management systems, a remote object management system couldarbitrate against stale arbitration values. The clear pending lock isthen released, as shown in step 670.

[0035] In an alternative embodiment, the local write lock 210 count andarbitration count can be combined into one variable. That is, theskeleton write lock 210 release code can be consolidated into a singlestage process, thereby reducing inter-object management system messagetraffic. This version requires the lock to keep the history of thearbitration variables for the last owner of the write lock 210. Thearbitration function would require that if the same object managementsystem is re-arbitrating for the lock after having owned the previouslock, then the random number it uses to generate its arbitrationpriority may not be the same as the number it used previously. Duringarbitration, an object management system can detect that the arbitrationvariables are stale and adjust the arbitration and write lock 210 stateaccordingly. This optimization is complicated by the notion that thewrite lock 210 release for the old lock and the next request may appearout of order if there are more than two object management systems. Ifthe code is not written carefully, an object management system receivingout of sequence release and request messages would be excluded from theopportunity of participating in the arbitration contest.

[0036]FIG. 7 shows the steps involved in a remote write lock 210release. As explained in the preceding section, this activity occurs intwo stages. First, as described in step 710, the clear pending lock isset to prevent the local object management system from processinganother request until the current lock has been released from all remoteobject management systems. The write lock 210 contention mutex is thenlocked and the write lock 210 contentions variables, writeidentification and priority, are cleared, as shown in step 720. Thewriter's lock 210 is then cleared from the local lock component, asillustrated in step 730. The lock contention mutex is released, asdescribed in step 740. In the second stage, the clear pending lock iscleared, as shown in step 750. The second stage occurs after the ownerof the write lock 210 on all connected object management systems hasperformed the first stage.

[0037] While the above description refers to particular embodiments ofthe present invention, it will be understood to those of ordinary skillin the art that modifications may be made without departing from thespirit thereof. The accompanying claims are intended to cover any suchmodifications as would fall within the true scope and spirit of thepresent invention.

[0038] The presently disclosed embodiments are therefore to beconsidered in all respects as illustrative and not restrictive; thescope of the invention being indicated by the appended claims, ratherthan the foregoing description. All changes that come within the meaningand range of equivalency of the claims are therefore intended to beembraced therein.

What is claimed is:
 1. A system to synchronize object management systemshaving a plurality of object management system components, comprising: adistributed reader and writer's lock for each of the plurality of objectmanagement system components that communicates over a language interfaceand controls access to information shared by a corresponding objectmanagement system component within multiple object management systems; amodule that creates the distributed reader and writer's lock and servesas an agent for the object management system component; and a listcontroller, which maintains a communications list and is adapted forcommunication with a communications controller, to which the distributedreader and writer's lock offloads management of a stub interface;wherein the distributed reader and writer's lock functions to: request alocal read lock and release a read lock; request a local write lock andrelease a local write lock; and request a remote write lock and releasea remote write lock.
 2. The system of claim 1, wherein each distributedreader and writer's lock communicates with corresponding locks on otherobject management systems through an ix_ring object that serves as aring buffer.
 3. The system of claim 1, wherein the distributed readerand writer's lock provides two callback functions while registering as aclient of the list controller.
 4. The system of claim 3, wherein onecallback function is the creation and initialization of an ix_base_tobject as a stub interface to a new object management system beingconnected to the system.
 5. The system of claim 4, wherein the languageinterface performs the initialization of the ix_base_t object generatedstub initialization function.
 6. The system of claim 3, wherein onecallback function is the clean up and destruction of an ix_base_t objectwhen an object management system is disconnected from the system.
 7. Thesystem of claim 6, wherein the language interface performs the clean upof the ix base t object generated stub clean up function.
 8. The systemof claim 1, wherein the module may have only one write lock at a timeand several read locks.
 9. The system of claim 8, wherein the write lockis granted to the module upon a release of all outstanding read locksand a grant and release of all outstanding read lock requests.
 10. Thesystem of claim 1, wherein the language interface uses an ix_base tobject to support a skeleton interface, which supports an incomingmessage, and an ix_base_t object to support a stub interface, whichsupports an outgoing message.
 11. The system of claim 1, wherein thelist controller provides a function to iterate through the distributedreader and writer's lock ix_base_t objects.
 12. A method of requesting alocal write lock, comprising: waiting for a drop in pending status of awrite lock, if a write request is pending; incrementing a pendingsemaphore; incrementing a local write lock count, if a local module hasthe write lock; locking a lock contention mutex and creating a randomnumber for resolving write lock contention; checking a variablededicated to write lock arbitration counting; incrementing thearbitration count; setting the write lock's arbitration identificationand setting its priority by generating a bound random number; releasingthe lock contention mutex; and making a write lock request.
 13. Themethod of claim 12, wherein the write lock's arbitration identificationis set to an identification of a local object management system.
 14. Themethod of claim 12, wherein if the write lock request fails because ofcontention, the local lock write count is decremented.
 15. A method ofrequesting a local read lock, comprising: passing a local read lockrequest to a local lock component; granting or blocking the local readlock request; retrying if the local read lock request is blocked; andrepeating until a maximum number of retries is reached.
 16. The methodof claim 15, wherein the local read lock request is blocked if a remotemodule owns a write lock.
 17. A method of requesting a write lock from aremote module, comprising: locking a lock contention mutex and checkingan arbitration count; resolving contention for a write lock orincrementing the arbitration count; and releasing the lock contentionmutex or forwarding the request to a lock component.
 18. The method ofclaim 17, wherein if the arbitration count is not greater than zero, thearbitration count is incremented.
 19. The method of claim 17, wherein anarbiter examines a priority value and identification value.
 20. Themethod of claim 19, wherein if a requested priority differs from acurrent priority, an arbitration winner is decided by the priorityvalue.
 21. A method of releasing a local write lock, comprising: settinga clear pending lock; locking a write lock contention mutex anddecrementing a write lock count; clearing write lock contentionvariables, if the write lock count is zero; releasing the lockcontention mutex; calling a write lock release function; and releasingthe clear pending lock.
 22. The method of claim 21, wherein the clearpending lock is set to prevent a local object management system fromprocessing another request until the lock is released from remote objectmanagement systems.
 23. The method of claim 21, wherein calling a writelock release function occurs in two stages of clearing arbitrationvariables and enabling arbitration for a following request.
 24. Themethod of claim 21, wherein a write lock count function and arbitrationcount function are combined into one variable.
 25. A method of releasinga remote write lock, comprising: setting a clear pending lock; locking awrite lock contention mutex and clearing write lock contentionvariables; clearing a writer's lock from a local lock component;releasing the write lock contention mutex; and clearing the clearpending lock.
 26. The method of claim 25, wherein the write lockcontention variables are identification and priority.
 27. A system for alocal write lock request comprising a computer readable medium and acomputer readable program code stored on the computer readable mediumhaving instructions to: wait for a drop in pending status of a writelock, if a write request is pending; augment a pending semaphore;augment a local write lock count, if a local module has the write lock;lock a lock contention mutex and create a random number for resolvingwrite lock contention; check a variable dedicated to write lockarbitration counting; augment the arbitration count; set the writelock's arbitration identification and set the write lock's priority bygenerating a bound random number; release the lock contention mutex; andrequest a write lock.
 28. The system of claim 27, wherein the writelock's arbitration identification is set to an identification of a localobject management system.
 29. A system for a local read lock requestcomprising a computer readable medium and a computer readable programcode stored on the computer readable medium having instructions to: passa local read lock request to a local lock component; award or deny thelocal read lock request; retry if the local read lock request is denied;and repeat until a maximum number of retries is reached.
 30. The systemof claim 29, wherein the local read lock request is denied if a writelock is owned by a remote module.
 31. A system for a remote write lockrequest comprising a computer readable medium and a computer readableprogram code stored on the computer readable medium having instructionsto: lock a lock contention mutex and check an arbitration count; resolvecontention for a write lock if the arbitration count is greater thanzero, or augment the arbitration count if the arbitration count is notgreater than zero; and release the lock contention mutex or forward therequest to a lock component.
 32. The system of claim 31, wherein theinstructions are adapted to provide to an arbiter to examine a priorityvalue and identification value.
 33. A system for a local write lockrelease comprising a computer readable medium and a computer readableprogram code stored on the computer readable medium having instructionsto: set a clear pending lock; lock a write lock contention mutex anddecrement a write lock count; clear write lock contention variables, ifthe write lock count is zero; release the lock contention mutex; call awrite lock release function; and release the clear pending lock.
 34. Thesystem of claim 33, wherein the clear pending lock is set to prevent alocal object management system from processing another request until thelock is released from remote object management systems.
 35. A system fora remote write lock release comprising a computer readable medium and acomputer readable program code stored on the computer readable mediumhaving instructions to: set a clear pending lock; lock a write lockcontention mutex and clear write lock contention variables; clear awriter's lock from a local lock component; release the write lockcontention mutex; and clear the clear pending lock.
 36. The system ofclaim 35, wherein the write lock contention variables are identificationand priority.